Many businesses, organizations or the like rely on databases that store non-public information (NPI). For example, financial institutions, such as commercial banks, implement databases that provide for storing credit card tables and related information. Such highly sensitive databases require monitoring for the purpose of track the use of such databases and ensuring that the non-public information is kept as such.
In many instances, businesses and organizations implement database monitoring applications as a means of monitoring the databases that store highly sensitive and/or non-public information. For example, Guardium® of Waltham, Mass. provides commercial database monitoring applications are. Such commercial application implement firewalls or the like that serve to prevent authorized users from performing unauthorized actions such as executing queries on sensitive table, changing sensitive data values, adding or deleting critical tables, creating new user accounts, modifying privileges and the like. The firewalls or the like provide for comparing the authorized users credentials to stored access credentials to determine if the user is authorized for access. If the user's credentials do not match those stored, access is denied to the user and the database connection is dropped.
However, known commercial applications for database monitoring tend to be decentralized or distributed systems. This means that access lists, otherwise referred to as “blacklists”, are apparatus specific; each database monitoring apparatus has its own blacklist associated therewith. As such, managing of the blacklist across a business or organization becomes a difficult task, in that a change to the business-wide or line of business-wide blacklist requires that a change be made to each blacklist associated with each database monitoring apparatus. The need to make multiple changes to multiple blacklists is prone to error and results in inconsistency amongst the multiple blacklists.
Additionally, known commercial applications require that two changes to the blacklist be made when a user is given temporal access to a database. For example, a first change to the blacklist is implemented when a user is given access to a database (i.e., removed from the blacklist) and a second change to the blacklist is required when the user no longer requires access to the database (i.e., added back to the blacklist). Such a need to perform multiple changes to the list when a user is provided temporary access to a database is also susceptible to error, in that, often times the second change, which adds the user back to the blacklist (i.e., blocks the user from access), fails to occur. In such instances in which the user is given temporary access but is not added back to the blacklist after the expiration of the temporary time period, the database is compromised by being accessible to users that should be authorized for such access.
Therefore, a need exists to develop methods, devices, computer program products and the like for managing the access to databases that store highly sensitive/non-public information. The desired methods, devices, computer program products should provide for central management of database access, such that a change to the access list is incorporated business-wide, line of business wide or the like without the need to individually update or change each access list corresponding to a specific access monitoring system. Moreover, by providing for centralized management higher scalability can be achieved and tighter access control is placed on to whom and under what condition a change to database access can be granted. In addition, the desired methods, devices, computer program products should obviate the need to perform multiple updates/changes to the access list in the event that a user is provided temporary access to the database. Additionally the desired methods, devices, computer program products should improve reporting and auditing of database access management.